Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000023_owner-urn-ietf _Wed Oct 9 10:33:03 1996.msg

Internet Message Format | 1997-02-19 | 9KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA17788 for urn-ietf-out; Wed, 9 Oct 1996 10:33:03 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA17783 for <[e-mail]>; Wed, 9 Oct 1996 10:32:58 -0400
Received: from SMTP1.ABRAXIS.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA25734  (mail destined for [e-mail]); Wed, 9 Oct 96 10:32:54 -0400
Received: from [206.155.199.11] by smtp1.abraxis.com (NTMail 3.01.03) id ba052079; Wed, 9 Oct 1996 10:36:35 -0400
Message-Id: <[e-mail]>
Date: Wed, 09 Oct 1996 10:37:48 -0400
From: Michael Mealling <[e-mail]>
Organization: Network Solutions
X-Mailer: Mozilla 3.0b7 (X11; I; SunOS 5.5 i86pc)
Mime-Version: 1.0
To: Larry Masinter <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: [URN] advantages of NAPTR over PURLs
References: <96Oct9.021303pdt."2765"@golden.parc.xerox.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Michael Mealling <[e-mail]>
Errors-To: [e-mail]

Larry Masinter wrote:
>
> > The only way to do this is with a new record. That record is the
> > SRV record which a lot of people are planning on using. A records
> > only have the IP address, nothing else.
>
> Presumably if you have SRV records, you could use them for HTTP
> servers too, including http://www.purl.org. So the fact that this is a
> general mechanism means that 'priority' is no longer an advantage of
> NAPTR vs. PURL.

Do you see where you're going Larry? You are putting everything
we've already got in the URN framework and the NAPTR proposal
into PURLs.

> > Because it has "purl.org" in it which is OWNED by OCLC. They pay the
> > bill. As far as the NIC is concerned they can do with it whatever
> > they want and we can't do squat about it. NAPTR should eventually
> > be a TLD all its own that is not 'owned' by anyone but the IANA (which
> > has its own problems but I won't go into that).
>
> Look, every place I've said "purl.org", change it to "purl.net" and
> register "purl.net" in a standards track document, 'owned' by IANA.
>
> If you did that, what would distinguishes 'urn.net' and 'purl.net' in
> terms of longevity?

Nothing. But you ARE changing the intent and current design of PURLS.


> > Because we don't to be tied to DNS. The URN framework (not NAPTR)
> > works in all situations no matter if you have DNS or not. You
> > can run the service in an OSI world using X.500 (everyone scream).
>
> I'm sorry, I was trying to establish the advantage of the NAPTR
> implementation against the PURL implementation of URNs, not against
> the 'framework'.

NAPTR is just one implementation. Its not the best because of
limitations of DNS. If you've got problems with NAPTR because of
that then take them up with Paul Vixie. If you can come up with
a DISTRIBUTED database that has is as large and as widespread
as DNS that we can test the framework on then by all means let
us know cause we'll build the framework on that too.

If you've got a problem with NAPTR then you either have a problem
with the framework or DNS.

> > 1) Areas of Authority. purl.org is authoritative for everything. I doubt
> >    if that scales. If its not authoritative how do I find the authoritative
> >    server?
>
> Who is the authority of "urn.net"? The authority for purl.net can be
> delegated in the same way that NAPTR delegates the authority for
> urn.net.

Huh? How can purl.net delegate authority without having to go
through purl.net first? Who the authority is for urn.net is
the IANA hopefully. The IANA could also be the authority for
purl.net. That's not the issue. I'm talking about subdelegation
of entire naming authority spaces such as "ibm", "compuserve",
"thompson publishing", etc.


> > 2) Services. I don't want just the URL. I want a URC. But I want it in
> >    SGML and not MARC. How can I get that out of a PURL?
>
> This is really speculative, of course, since there's never quite been
> agreement on exactly what a 'URC' might be. But I'd conjecture that
> the way you get something out of a resource other than the resource
> itself is by applying some other method than GET.

Ok. Granted. URCs don't exist. What happens when the resource
itself on one server and the metadata is on another. To find
both I have to go to purl.net. Larry, I don't know if you've
got some awsome machine up your sleave but if you've got a database
that can a) handle HTTP b) be replicated reliably and quickly around
all of the SRV replicated PURL servers and c) handle the millions
of queries a second that are going to come to purl.net because
it is the one place that knows where all of the URNs and URLs and
URCs are then you've got something truly amazing. Who the hells
gonna pay for it?

>
> > 3) Other available protocols. The PURL doesn't tell me what other
> >    protocols are available and which one it considers the best.
>
> If the 303 response from HTTP includes multiple Location: results, you
> could pick the one you liked the best. It's true that the results
> don't rank order them, but is that actually practical?

Yes. If I'm serving SGML based something or others then I want you
to use Z39.50 or some other deep search tool. You should know
that even though you like HTTP its not going to get you the
information that I know is in that database.

Plus, I still have to go to one of those big purl database machines
even to find out what protocols are available.

You've done nothing more than stick the hidden the re-write rules
inside the PURL database and made everyone go to it in order
to do the mapping. You've basically collapsed the NAPTR proposal
into one BIG  PURL database by forcing everyone to go to it
in order to find out what the URLs are for the authoritative
resources.

That just won't scale.

> > 4) Equivalence. How do I match equivalence? Do I just match on
> >    the part after the hostname? If so then authority areas cannot
> >    exist. If not then your protocol is indistinquishable from the
> >    rest of the authority area.
>
> I'm not sure where the 'equivalence' requirement came from, since it
> was specifically not a URN requirement. It wasn't a URN requirement
> primarily because it was considered impossible.

One server gives me a document called URN:FOO. Another services gives
another document called URN:FOO. I know that for their purposes
those organizations think those two things are the same.

If I have http://foobar.purl.net/saldkfasldkfjsldfj and
http://barbaz.purl.net/saldkfasldkfjsldfj. Are they byte equal?

>
> > There is not ONE killer reason why the URN framework is better than
> > PURLs. There are alot of smaller ones....
>
> I think you misunderstood: I'm not questioning the 'URN
> framework'.

The framework specifies everything that NAPTR must do. DNS
specifies everything that NAPTR can do. How would you build
something that follows the framework that doesn't require
everyone to go to one HUGE replicated database? The only
widely available distributed database we have right now
is DNS.

I hope that won't be the case very soon. I'm building a
parallel registry in rwhois. It doesn't have the restrictions
that DNS does. Its more generalized and doesn't need to
be re-written everytime you add a field.

> I'm questioning the NAPTR implementation of the framework.
> I'm dubious about these DNS records with 'dblookup+N2C' in the middle
> of them and the idea that just because the syntax is embedded in DNS
> as a transmission mechanism that it isn't a 'protocol'.

Noone ever said it wasn't a protocol. Its a distributed
database for looking up the rules for finding the authoritative
servers and services for a given URN. The NAPTR proposal
gives the algorithm for interpreting the records in that database.
Of course in order to use that database you have to access it
somehow and thats a protocol.
--
------------------------------------------------------------------------------
Michael Mealling    | 505 Huntmar Park Drive       | Phone:  [phone]
Software Engineer    | Herndon, VA 22070           | Fax:    [phone]
Network Solutions    | <URL:http://www.netsol.com>  | [e-mail]